this "skip" on internal routes is already implemented deep inside bucket policies, inside isBucketAuthorized and isObjectAuthorized : is this redundant (i.e. we indeed call these later), or do we really need the extra skip here? In that case, should that check be added in handleAuthorizationResults ?

The check is not redundant, as far as i understood we are only supposed to skip bucket policies when using an internal Cloudserver not all the policies, so handling the flag at a higher level like in handleAuthorizationResults would disable all policy evaluation including for standard APIs which is not something we want.

handling the flag at a higher level like in handleAuthorizationResults would disable all policy evaluation including for standard APIs which is not something we want.

That explains why we want to keep the checks deep in isBucketAuthorized and isObjectAuthorized instead of moving it handleAuthorizationResults.

But should we not evaluate these "standard" policies on backbeat routes as well (i.e. remove this extra bypass, and just rely on the deeper bypass) ? Or is it something we can only do later, when we have added the required (custom) permissions in arsenal/vault and given them to the internal users?

We could evaluate policies on the internal Cloudserver, however i'm not certain our internal services have the required permissions (policies) hence why i skipped the evaluation here.

I created a follow-up ticket to verify the policies we create for our services and eventually remove this check (ZENKO-5058)